Unlike logical partitions (LPARs), in which computing resources are partitioned with respect to hardware, a virtualized file system is partitioned with respect to software. In addition, although LPARs which may have different operating systems, virtualized file system spaces typically include virtualized operating system (OS) environments within a single instance of an OS. One example of a virtualized file system space, used as an example throughout this Specification, is a workload partition (WPAR). It should be understood that although the claimed subject matter is described with respect to WPARs, the same principles also apply to other types of virtualized file system spaces.
Basically, there are two types of WPARs, system WPARs and application WPARs. Typically, a system WPAR partitions system resources and an application WPAR isolates and executes one or more application processes. The following description is based upon system WPARs. Each WPAR has a regulated share of system resources and may have unique networks and file systems. In addition, each WPAR may have separate administrative and security domains, with each WPAR having a unique root user, regular users and passwords, its own services such as inetd, cron and syslog, and can be stopped and started on its own. A WPAR does not typically share writable file systems with other WPARs or the global system. WPARs share an operating system and may share underlying file systems, real or virtual disk adapters, processors, memory, paging space and a real or virtual network card.
Although WPARs within a particular LPAR share one OS, different WPARs within a LPAR may run different versions of to particular OS. Such a WPAR is called a “versioned” WPAR. A versioned WPAR typically runs an older version of an OS than the global LPAR. The versioned WPAR contains commands, shared libraries, and so on of whatever level of OS it is running. However some commands, such as, but not limited to, device drivers and other kernel extensions, within a versioned WPAR are “overlaid,” which means that the WPAR, runs the corresponding command in the global LPAR. Typically, this is necessary to keep certain commands in sync with the kernel on the global LPAR because WPARs do not include their own kernel.
When a file is overlaid, the file is renamed, typically by adding a suffix to the name and the original file, or legacy binary, is replaced by a symbolic link to a copy of the native runtime execution wrapper. Typically, there is one copy of the native execution wrapper for each target binary's directory path. In addition, actions are taken to reflect these changes in data that an install facility uses to track the state of all installed files on the system and references to the original name replaced by the new name with the added suffix. The wrapper mechanism works as follows: 1) The path of the native library is pre-pended to the LIBPATH parameter; 2) The name of the executable that invoked the wrapper is identified; and 3) A special new “native runtime exec( ) interface” is called to execute the corresponding native binary.